Operating systems typically expect complete and direct control of hardware and system resources. As such, the operating systems implement policies to manage these resources to allow execution of various user applications. Frequently, a single application is dedicated to a single platform of hardware and system resources (e.g., industry standard servers) such that the application can not conflict with other applications, or vice versa. Additionally, in the event of the application failing, a separate backup platform of hardware and system resources may then be employed to execute the application. Other benefits to maintaining separate platforms of hardware include keeping various applications secure from one another. In such a case, even if one application contains a security flaw, potentially rendering the hardware and system resources vulnerable to attack, the attacker may not access additional data or services of that breached platform because there is only a single application executing on those resources.
Recently, there has been an increased interest in consolidating applications on a single server because, despite the low cost of such hardware, the cost of maintaining that hardware is high. Additionally, dedicating a single application to one server results in a significant waste of processing resources. Virtualization of processor hardware (e.g., industry standard servers) allows multiple instances of operating systems to run on a single system.
A virtualized computing environment includes one or more virtual machines (VM) that further include all the necessary hardware and system resources (processors, memory, disk, network devices, and other peripherals) that an operating system expects. A virtual machine monitor (VMM) is software that is operating between the hardware and as many VMs as required to service the operating systems. For each instance of an operating system, referred to as a guest operating system, the VMM creates a VM. Therefore, if a particular application in a guest operating system fails or crashes, it will have no effect on other operating systems operating on separate VMs of the virtualized computing environment. An alternate VM may, upon detection of the failure, operate as a fail-over server and execute the application, negating any need to cycle power for the system resources executing the failed application.
Because operating systems typically expect direct control and access to system resources, multiple operating systems executing on a single hardware platform could naturally result in conflict. Consequently, each operating system, and corresponding application(s) executing within the operating system, will typically execute unmodified and unaware that it has no direct access to the system resources. In such cases, the VMM isolates execution of each VM, and allocates resources for each VM in physical memory that does not overlap with other operating systems or applications concurrently using the underlying platform of hardware resources.
Processors may support a variety of modes ranging from full physical to full virtual mode, with various partial transition modes in between. An operating system may set physical or virtual modes independently for data, register backing store, and instructions. A transition occurs when one of these modes changes from physical to virtual, or vice versa. After a transition, care must be taken to maintain address integrity that has been designated as cacheable or non-cacheable address space. If an address has been designated as cacheable, it must not be changed to non-cacheable, or vice versa. Software based virtualization solutions today require complex workarounds to maintain address integrity. The VMM monitors operations of the operating system during runtime and takes control when the operating system attempts to access privileged platform resources. Upon completion of the operating system privileged process, the VMM returns control back to the operating system.
Such monitoring and processing in software greatly impacts processor performance. Most processors include a Translation Lookaside Buffer (TLB) to speed-up virtual to physical address translations. A TLB is a small amount of memory located within a processor that may store virtual to physical address translations. Such translations may be stored on a page and the TLB will typically store a small number of virtual address translations from the page that were most recently used. When an operating system or application attempts a memory access, it may issue a virtual address. The TLB is searched for that virtual address and, if found, the corresponding physical address may then be used to quickly access physical memory. If the virtual address is not found, however, the processor must translate the virtual address via a page table walk, thereby consuming significant processor resources.
The TLB may also fail to contain useful virtual addresses (and corresponding physical addresses) if it has been flushed. A TLB flush occurs when an application or operating system changes modes (e.g., from virtual to physical mode), sometimes referred to as a context switch. One particular concern leading to the TLB flush is to prevent any overlap between TLB entries that are used for guest physical addressing and entries that are used for guest virtual addressing. Effectively ensuring that no such overlap occurs during mode changes, while preserving useful TLB entries, remains an open problem.